home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 6683 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: surfnet.nl!sun4nl!xs4all!usenet
  2. From: jtv@xs4all.nl (Jeroen T. Vermeulen)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Speed: 68040 vs. 68060
  5. Date: Thu, 29 Feb 96 18:33:25
  6. Organization: Leiden University, Mathematics & Computer Science, The Netherlands
  7. Distribution: world
  8. Message-ID: <19960229.7B2B7F0.109E9@asd05-00.dial.xs4all.nl>
  9. References: <4foi00$60t@gondor.sdsu.edu> <3125E74D.3390@gih.no> <19960223.425E10.10CBD@an100.du.pipex.com> <19960225.7AF9790.E534@asd10-22.dial.xs4all.nl> <19960226.477570.1832@an174.du.pipex.com> <4grotj$8q3@serpens.rhein.de> <19960226.7B42F98.E8D9@asd06-03.dial.xs4all.nl> <19960226.43B8E8.EF50@ai038.du.pipex.com> <19960227.7AD21D0.FF6A@asd06-24.dial.xs4all.nl> <19960228.652C38.1B4E@ak138.du.pipex.com>
  10. NNTP-Posting-Host: asd05-00.dial.xs4all.nl
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=iso-8859-1
  13. Content-Transfer-Encoding: 8bit
  14. X-NewsSoftware: GRn 2.1 Feb 19, 1994
  15.  
  16. In article <19960228.652C38.1B4E@ak138.du.pipex.com> m.hendry@dial.pipex.com (Mathew Hendry) writes:
  17.  
  18. > : > : Not necessarily in this case.  What I meant is that the timing routines may
  19. > : > : include time spent on other tasks.
  20. > : >
  21. > : > That's irrelevant. The intention is to see how long the algorithms take on a
  22. > : > real system (in real time, not in CPU time). On a real system, running a real
  23. > : > application, you will also have other tasks "stealing" CPU time, which
  24. > : > increases the real time taken to complete a task.
  25. > :
  26. > : On a real system, you will usually want to do several things at the same time
  27. > : (even if it's just for hiding I/O latencies).  So whether or not a system is
  28. > : multitasking is hardly irrelevant.
  29. >
  30. > I didn't say it was. The difficulty is that if you only measure the CPU time
  31. > taken and not the real time, then you are effectively ignoring the fixed
  32. > overheads present on that system, which could in some cases give a very
  33. > distorted measure of real performance.
  34. >
  35. > These benchmarks were designed to test an OS / hardware combination. The
  36. > documentation makes this very clear. Only measuring the CPU time taken would
  37. > remove any consideration of the OS from the results.
  38.  
  39. You're right, of course.  But I still feel that comparing single-tasking systems
  40. against multitasking ones in a benchmark like this will flatter the
  41. single-tasking ones, and this should be taken into account by a _user_
  42. interpreting the results.  Even if the raw performance measurements can be
  43. argued to be fair, the single-tasking systems cannot in general live up to the
  44. expectations created by their benchmark performance.
  45.  
  46. If you spend a lot of time on I/O, for instance (not unusual I'd say :-) then
  47. performing two tasks simultaneously on a multitasking system can be done faster
  48. than doing them sequentially as you're forced to do in a single-tasking
  49. environment.  Yet the BYTE benchmark would report the single-tasking system to
  50. be faster in that case!
  51.  
  52. [ Notable exception here is Windows 95 which has been reported to perform
  53.   *worse* when multitasking than performing the two tasks sequentially ]
  54.  
  55.  
  56. > -- Mat.
  57.  
  58. --
  59. ============================================================================
  60. #  Jeroen T. Vermeulen   \"How are we doing kid?"/   Yes, we use Amigas.   #
  61. #---  jtv@xs4all.nl    ---\"Oh, same as always."/--         ...          --#
  62. #jvermeul@wi.leidenuniv.nl \ "That bad, huh?"  /  Got a problem with that? #
  63.